Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_1199/908

Internet Message Format | 1994-08-27 | 8KB

From: [e-mail] (Michel Forget)
Subject: Re: Gem List (fwd)
Date:     Tue, 19 Jul 1994 21:48:56 -0600
Precedence: bulk

Ken:

>I didn't make *any* mention about changing the keyboard focus. Why bring
>that up at all since it wasn't even mentioned?

The reason I mentioned the keyboard is because the user will expect output
to go to the top window when typing.  This has been a key aspect of
GEM forever, and the user will expect it to hold true.  If there is
not top window, or output goes to a window that is not topped, that
is a confusing behaviour.  Perhaps XWindows handles this nicely, but
it -started- that way.  Changing now would confuse the user
needlessly.

>GEM is not going to change to match my philosophy; so we're writing a
>GEM Library to *match* the philosophy. There is no reason why users have to
>be stuck in the dark ages in terms of a user interface.

I'm not sure I understand your emphasis?  Match -what-?  The GEM
philosophy (topped windows and all the other stuff you hate but is
standard) or your own philosophy?  Coud you be more clear on this.

>> Here is an idea; why not try MausWind, and be happy.  It will
>> automa[t]ically top the window as the mouse passes over it.  It is a very
>> nice program, written by Thomas Binder.
>
>That is exactly the kind of thing I hate, auto-window-topping. If you had
>actually read my message, you would have realized that.

I did read your message, and I thought that this was a nice suggestion.
If you do not want to top windows yourself, why not let the system do
it so that you do not have to deal with it?  From the way you speak, this
offends you to the core of your being...  :)

>It's confusing in that it's a non-consistent GUI design. There is no reason
>why programmers have to be content with atari's stupid mistakes.

There is one reason; the user expects it.  Small changes that improve the
design are fine, of course, but major changes that shatter the old
design are not fine.

>Other than the idiotic design in AES 4.x for hierarchical menus.

I was talking about the menu layout, not the method of building a
hierarchical menu.  I haven't honestly looked at that.

>We *did* do it right. If you had a copy of the demo program and used it, you
>would never be able to tell that we do these so-called "time wasting" things,
>unless we told you.

Okay, Ken.  _Send_ me a copy, if you are willing, and I will look at it
and summarize the experience to the list.  Does this sound fair?  I'll
look at it objectively and tell you what I think.  This is about the
tenth time you've said to someone that if they had only seen the
demo copy they would be Might Impressed.  Well, if you were honestly
offering, then send me a copy to [e-mail]
and I will look at it and (maybe) be Might Impressed.

>Wrong. Our library is much *smaller* than Gem++, yet has many more features.
>The resulting executables that do the *same thing* as the equivalent Gem++
>program are generally several times *smaller*, not to mention *faster*.

GEM++ is a mega-library, though.  Of course it is big.  As for the size
and speed, consider that you are using Pure C and GEM++ uses the
monster-compiler C++.  How big is your library compared to EGEM, or
SGEM, or ForceGEM?  Those are the biggest libraries I can think of
for Pure C.  How does your library fit in with these?  (What is the
actual SIZE of your library, for example?)

>Maybe you'll become confused by a straighforward GUI design, but I think
>you'll be just about the only one. :-) Changing the mouse button requirements
>for selection of a topped dialog and a background dialog are totally against
>a sane GUI design. But then again, nobody ever claimed atari is sane :-)

Er, what?  I never said you should have to push a different button to use
a background window.  I like the way Atari does it with MultiTOS, where
you can use the left mouse button to operate the gadgets of a background
window.

>Yet you criticize us for improving on the wheel. Where do you draw the line?

I draw the line at the point where you start changing the GUI so completely
that a casual GEM-user would be confused by your changes.  Programs that
are hard to learn do not get used, unless they are really, really great
programs.

>WinLIB PRO was designed after intensive study of over *20* GUI libraries.
>It incorporates the best ideas of all of them (we steal from the best, and
>forget the rest :-) WinLIB PRO is extremely powerful, yet extremely
>easy to use. WinLIB PRO does most of the work for you, with an extremely
>straightforward, simple API.

If you send a copy of the demo program to me, I'll be more than happy
to take a look at it and report my findings to the list about whether or
not you have the key to GUI perfection.  Mind you, if it crashes my
system I'll mention that too.

>Sozobon produces good object code? *laughs* I think your standing with most
>of the people in this conference has dropped about 20 points from that
>comment alone. Sozobon code is mediocre to fair, but far from 'good'.

SozobonX 2.00 (Jerry G. Geiger) -- I never claimed in was Pure C, but
it does produce good code.  Programs compiled with it are always smaller
than those compiled with GNU C, in my experience.  As for my standing,
I'm not much worried about that.  I use the compiler I use, because
it does what I want.  Also, consider that I was using HSC before
SozobonX, and SozobonX cut over 96K of memory usage off of the
previous version of MasterBrowse (compiled with HSC) and about
36K of disk space.  I'd say that that is a reasonable definition of
"good", wouldn't you?  Oh, by the way, SozobonX apparently works with
the Falcon. Pure C, on the other hand, does not.

>> >Better yet, break out a debugger and check things out for yourself. You DO
>> >know how to use an assembler-level debugger do you not?
>> Maybe he does, but I do not.  That would require assembly language
>> programming skills, which not everyone has (or needs).
>
>I think that if people in this conference spoke more from EXPERIENCE and less
>from OPINION, we would be much more productive.

I'm not sure I follow your comment.  My -experience- is that I do not know
assembly language, and therefore have no real use for an assembly level
debugger.  What on earth can you possibly object to in that?

>It's not a problem because you should not be storing list items in the
>dialog itself, but rather using the dialog as a 'window' to the list. You're
>saying that a text editor should store the entire document in the resource
>structure itself? That's silly. Besides, the size of the slider corresponds
>to the number of units it can move.

I was not saying anything.  I was asking for clarification.  Now that you
have made it clear, the problem is solved.

>(I could go into a discussion on memory fragmentation from alloc'ing and
> free'ing memory for dynamically growing and shrinking a listbox, but I
> digress...)

You could, but why?  You could also mention that using Malloc() more than
sixteen times on a TOS 1.0 machine will crash it.  Not an easy problem
to get around.  None of this is on topic, though.

>I'm not insulting every programmer who would consider using it. From the
>very beginning, you have been against WinLIB PRO -- it sounds like you
>would have not used WinLIB PRO anyways, so nothing lost.

>From the "very beginning"?  When you were distributing demonstration
versions of the program last year, on the FNET, I was very supportive
of the idea.  As I recall, I did not say anything bad about it (other
than that it crashed fairly regularly, which it did).  If you mean
from the beginning of this list, I'd say you are wrong again.  I'm
against changing the basic GUI design of the Atari.  I do not actually
have anything against you or your library.  Why would I?

>(WinLIB PRO already has a following, btw.)

Good, then.

At last, this mega-message is over.  Now Ken can correct more of my
spelling mista[k]es...  :)


--
Michel Forget           \\   [e-mail]    //
Electric Storm Software  \\  [e-mail]               //
PGP Public Key Finger. = 1F C0 D3 FE 40 51 7F 47 F